The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field. Still more particularly, the present invention affords an improved correlation between source code in a source code view pane and a corresponding control in a graph view pane in an IDE.
Visual design tools are often used to help designers develop and build Graphical User Interface (GUI) programs and/or web pages. These visual design tools usually have a rectangle drawing area called a “Design” view (a.k.a., “graph view pane”) which allows the designer to lay out various GUI controls in a WYSIWYG (“What You See Is What You Get) manner. GUI controls (or widgets) are usually things like labels, text objects, tables, etc., which are used in the construction of the overall GUI.
Depending on the technology for which the visual tool is being used, source code is generated to allow the GUI to be executed in the runtime. For example, HyperText Markup Language (HTML) or a Java Servlet Page would be generated for a Web interface type application, or Java code would be generated for a Java based GUI application. Oftentimes it is necessary to access the source code in order to set additional properties or to write business logic to be executed when an action is performed on one of the GUI controls. For example, an HTML form with a “Submit” button may need to have some logic added to the button so when it is selected, it gathers the data from all the controls on the page and sends it to the server to be processed.
The visual tool also usually provides a “Source” view (a.k.a., “source code view pane”) to allow the designer to add the additional code needed to get the desired behavior. In the source view, code assistance is also available to help the designer with applying various actions or methods to the targeted control or for accessing the control in order to retrieve information (e.g. the text information from a text field). FIG. 1a shows an example of a GUI 100 that contains a number of text fields 102a-e. The user can tell visually which text field 102 is used for which purpose. As shown in exemplary form in FIG. 1a, the topmost text field 102a is for entering the user's name, the one beneath (text field 102b) is for entering their password, and so forth. This knowledge comes from the visual placing of the controls on the GUI and their relationship to labels, tab titles, or other visual cues such as column headers. It is a cognitive process whereby the designer, and the user, know which text box is used for entering which piece of data.
By contrast, in the actual program that the developer uses to construct the GUI, the fields may be known by more anonymous names. In the example above, which was built with a GUI tool, the text fields 102a-e were named text1, text2, text3 and so forth, as shown by the code depicted in FIG. 1b. The problem is that at development time, when the user wishes to access a particular text field, such as to get or set its contents or perform other logic, the source program only knows them by their semantic names. An example of this is during code assist (a feature designed to help the user identify which program artifacts they can use), in which the list presented contains the fields only by their names, as shown in the code depicted in FIG. 1c. This means that if the user wishes to perform the step “get the contents of the e-mail field”, they need to know which of the fields it is by name. It may be that it is text3 because it is the third field down on the GUI; or it may be that text3 is on another notebook page that was created first before the “User” tab was created; or it may be that text3 was created and deleted and in fact the Email field is text9. Thus, fields can be dropped and moved and re-ordered, and the problem that this invention tackles is how the user can relate a semantic field name to its visual occurrence on the GUI.
Thus, in the example shown above, assume that the user wishes to set the contents of the user's name. For this the code developer (designer) needs to access the text field corresponding to the “Name” in the application. This requires the following five steps:    Step 1. In the source view, the designer looks at the code generated for each of the text controls and tries to determine which text control should be accessed. The names are not named in a way that makes it easy to find as they were generated by a GUI builder tool.    Step 2. Since it is not clear which control corresponds to the “Name” text field, as illustrated in the code shown in FIG. 1d, the designer must determine what the name of the text field to the right of the “Name” label is, and does this by navigating to the Design view. This step means that the cursor loses focus from the source view, so when the designer has eventually determined the name, he must return to the source tab and relocate the cursor at the position where it previously was.    Step 3. In the “Design” view, the user selects the text field 102a to view its properties, as shown in FIG. 1e. The “Properties” view 104, shown in FIG. 1f, will list all the properties for the text field that should include the field name of the control.    Step 4. The designer navigates to the “Properties” view and scrolls down through the properties to get to the name of the text field. He must then make a mental note of what that text field is called—in this case “text1.”    Step 5. Rather than make a mental note, and since the name may be long and machine generated, the designer might select the name and copy it to the system clipboard for later pasting into the source view, as shown in GUI 106 in FIG. 1g.     Step 6. The designer navigates back to the source view, scrolls down to the code he was previously at in Step 1, presses “Enter” to create a new line to begin writing code (as shown in FIG. 1h), and then pastes the name of the control into the source code or enters it by hand having remembered the name seen in Step 4.
These just described steps are time consuming, distracting, and prone to error, since the designer may inadvertently apply additional logic to the wrong control in the source view if the name were typed in from memory instead of using copy/paste. A solution is needed that allows the designer to easily pick the targeted control while in the source view and have the name of the control placed in the context of the source code without having to go through the many tedious, distracting steps just described.